Skip to main content

01 - 训练环境为什么不是运行时沙箱

前置:不需要。读过 Agent 执行沙箱 · 01 - 为什么需要沙箱 会更顺,但不是必需。

本篇回答:生产上已经有沙箱了,为什么训练还要另做一套?两者在负载形态上到底差在哪、差多少?

本篇会用到的词

意思
RL(强化学习)让模型通过「试—打分—调整」来学习的训练方式。和监督微调的区别是:没有标准答案,只有一个给行为打分的函数
rollout一次完整的「让模型去试一遍」。模型在环境里连续动作若干步,直到任务结束或超时,产出一条轨迹
轨迹(trajectory)一次 rollout 的完整记录:每一步的观察、模型的动作、拿到的反馈,以及最终得分
环境(environment)接收动作、返回观察和奖励的那个东西。对 Agent 来说,它通常就是一台装好了工具的 Linux 机器
奖励(reward)给一次 rollout 打的分。代码任务里通常是「测试跑没跑过」,这类可自动判定的奖励叫可验证奖励
reset把环境恢复到初始状态,好让下一次 rollout 从同一个起点开始。这是训练环境和运行时沙箱最大的分野
on-policy训练数据必须由「当前这一版模型」产生。它意味着环境不能提前跑完存起来,必须和训练同步产出

一、先看一次 RL rollout 的完整链路

训练一个 Agent 和训练一个聊天模型,差别不在损失函数,在数据从哪来。

聊天模型的训练数据是静态的:一堆现成的问答对,读进来就能算 loss。Agent 的训练数据必须当场生成 —— 模型得真的去操作一台机器,操作的结果决定了这条数据长什么样、值多少分。

一条训练数据是怎么被「跑」出来的训练器拿轨迹更新参数GPU 密集当前参数推理引擎生成下一个动作GPU 密集动作环境一台装好工具的 Linux 机器CPU 与 IO 密集,不吃 GPU观察 · 回到上一步,循环几十次判定器测试跑过了吗给出奖励整条轨迹(每步的观察 · 动作 · 最终得分)回流给训练器中间那个绿色方框就是本专题的主题。它不吃 GPU,但它决定了另外两个吃 GPU 的环节有没有活干 ——环境起得慢、并行度上不去,几千张卡就在那儿等着,这是 agentic RL 里最贵的一种空转。
注意环境处在循环内部:一次 rollout 要和它交互几十个来回,而一轮训练要并发跑几千上万条 rollout。环境的单次延迟会被这两个数字连乘放大。

看懂这张图,就能理解为什么训练团队要专门做一套环境基础设施:GPU 很贵,而喂饱 GPU 的是 CPU 侧的环境。

二、和运行时沙箱的四处根本差异

Agent 执行沙箱那个专题讲的是生产环境:一个用户开一个沙箱,跑几分钟到几小时,跑完销毁。训练环境的负载形态完全不同。

同样是「一台隔离的 Linux 机器」,两种用法要的东西不一样维度运行时沙箱(生产)训练环境(RL)谁在用真实用户,一人一个,交互式训练进程,批量拉起,无人值守并发规模同时几百到几千个同时几万到几十万个,且随训练波峰波谷抖动单个生命周期分钟到小时,起一次用很久秒到分钟,起停本身成为主要开销要不要 reset不需要,用完就销毁必需 —— 每条 rollout 都要从同一个起点开始可复现性不要求强要求,环境漂了实验就没法对比
右边四行深色格子,每一行都能把一套只按生产场景设计的沙箱系统压垮。它们不是「更高的要求」,是不同性质的要求。

2.1 并发规模:从几千到几十万

生产上的沙箱数量由活跃用户数决定,涨得慢、可预测。训练时的环境数量由「一轮要采多少条轨迹」决定 —— 这个数字直接和 GPU 数量挂钩,而且是阶跃式的:一轮 rollout 开始时瞬间要几万个环境,采完了瞬间不要了。

按生产思路做的沙箱平台在这里会撞两堵墙:调度器扛不住每秒上千次的创建请求;以及镜像分发——几万个环境要用几百种不同的镜像,每台机器都预热一遍是不可能的。

2.2 生命周期:起停开销成了主要成本

生产沙箱起一次用几十分钟,冷启动花 2 秒没人在意。训练环境可能只活 30 秒,冷启动 2 秒就是 6% 的纯浪费,再乘以几十万次。

这就是为什么训练侧的系统会把冷启动做到 50 毫秒级 —— 不是为了体验好,是为了把这部分开销压回噪声。

2.3 reset:训练环境独有的原语

这一条是最本质的差异。

RL 要求每条 rollout 从同一个初始状态出发,否则拿到的奖励没法互相比较。生产沙箱没有这个概念:用户开一个新沙箱就是新的,脏了就丢掉重建。

训练环境不能这么办 —— 重建一次要装依赖、拉代码库、跑初始化脚本,可能几十秒。所以训练侧的做法是快照 + fork:把初始状态做成一个快照,每条 rollout 从快照 fork 出一个独立副本,用完丢弃,快照本身不动。

每条 rollout 都要回到同一个起点 —— 两种做法重建拉基础镜像装依赖拉代码库跑初始化脚本几十秒 · 每条都要付一遍快照 + fork上面那四步只跑一次,做成快照初始快照rollout 1 的副本rollout 2 的副本rollout 3 的副本 · · ·毫秒级副本之间互不可见,写操作走写时复制,快照本身永远不变。
fork 出来的副本共享同一份只读底座,各自只持有自己改动的那部分。几万个副本的总存储开销,接近一份快照加上几万份「差异」。

2.4 可复现性:环境漂了,实验就废了

生产上没人在意「同一个沙箱两个月后跑出来是不是一样」。训练在意 —— 如果这一轮的环境和上一轮不一致,你没法判断分数变化是模型进步了还是环境变了。

具体会漂的地方:镜像里的包被上游更新、任务依赖的外部 API 改了返回、机器时区不同。所以训练环境要求镜像按 digest 钉死、外部依赖尽量本地化、时间与随机种子可控

三、为什么不能直接拿生产沙箱来训练

可以,规模小的时候完全可以,很多团队就是这么起步的。撑不住的临界点通常出现在这三处:

撞墙的地方具体现象
镜像分发几百种任务镜像 × 几百台机器,预热不现实;不预热则冷启动被拉长到分钟级
空闲成本rollout 之间环境闲着,但内存还占着。几万个环境按峰值配内存,机器数被空闲期决定
reset 语义缺失只能靠「销毁再新建」模拟 reset,于是每条 rollout 都要重新付一次初始化成本

02 篇拆的 AgentENV,正是逐条回应这三件事的一个实现 —— 它是给 Kimi K3 的 agentic RL 训练供环境的那套系统。

四、什么时候不需要这一层

规模没到就别上。 判据很直接:

  • 一轮训练的并发环境数在几百以内,且单条 rollout 跑几分钟 —— 直接用 Docker 或现成的托管沙箱,起停开销占比很低
  • 任务本身不需要一台完整机器(纯文本推理、单函数评测)—— 用进程级隔离就够了,执行沙箱 05 篇的判断树在这里同样适用
  • 还在验证「这个任务能不能训得动」的阶段 —— 先用最笨的方式跑通,环境基础设施是等你确定要长期投入之后才值得做的

下一篇02 - AgentENV 拆解:一个把冷启动压到 50 毫秒、支撑 150 万镜像的实现,它每一处设计对应上面哪个约束。

← 回到 专题索引  ·  Agent Infra 板块总览